사이클 2

기능

• 배팅 금액 입출력 기능 구현
• 전체 배팅 금액 구하는 기능 추가
• 최종 수익 출력하는 기능 구현
• 배팅 금액 예외 시 재입력 기능 추가
• 플레이어 burst면 상금 잃는 기능 추가
• 딜러 수익 계산 금액 기능 구현

사이클1 피드백 반영

• Player의 필드 List를 일급컬렉션 Cards로 변경
• 기존 Cards는 전체 카드를 의미해서 Player에서 사용 못했습니다.
  이번 수정 과정에서 전체 카드는 Deck이라는 도메인을 추가하고, Cards는 Player가 들고있는 카드 뭉치로 사용했습니다.
• Dealer와 Player의 상속 관계를 제거
• Dealer와 Player의 상속 관계로 인해 Dealer가 몰라도 되는 Player의 행동을 상속받고 있었습니다.
  이를 해결하고자 Player와 겹치는 행동은 Player에서 처리하고, 딜러의 규칙은 곧 게임의 규칙이기에 Game에서 처리하도록 변경했습니다.
• 도메인에서 DTO 직접 생성했던 것을 Service에게 책임 이동
• Controller에서 출력하는 책임을 OutputView로 이동
• 하드 코딩 상수화
• 사용하지 않는 import 정리

To 리뷰어

1.Dealer - Player
딜러의 행동(ex. 자신이 가진 카드의 합 구하기)은 Player와 중복이고,
딜러의 규칙(ex. 16이하이면 카드를 추가로 받는다.)은 게임의 규칙이기에 Game에서 처리할 수 있다고 생각했습니다.
객체에서의 책임은 현실세계와 차이가 있어서, 꼭 딜러가 하는 행동이라고 Dealer에 있어야하는 것이 아니라 응집도를 고려해 다른 곳에 위치할 수 있다고 생각하는데, 이런 구조로 구현하는 것에 대해 피드백 받고 싶습니다.

(이런 구조 → 코드 중복을 줄이기 위해 Dealer 객체를 없애고, 관련 행동과 규칙을 적절한 클래스에 둔다)

2. Domain
   지금 변경한 도메인 구조가 잘 짜여진 것인지 피드백 받고 싶습니다. 어찌보면 Game이 aggregate root와 같다고 보이는데, 이런 구조가 적절할까요?

3. 테스트 수정
   도메인이 대거 수정되니, 테스트 코드도 다시 수정해야하는 상황이 발생했습니다.
   본 코드랑 테스트 코드의 의존성이 큰거 같은데, 테스트 코드가 변경에 유연하게끔 작성하는 방법이 있을까요?

4. 코드 수정
   이미 사용중인 서비스에서는 이와 같이 도메인을 대거 수정하는 과정이 어려울거 같은데, 대거 수정이 필요할 경우 어떻게 해야하는지 궁금합니다.
   (하나를 고치면 여러개가 에러나는 상황이다 보니, 저는 전부 주석해놓고 처음부터 하나씩 주석을 해제하고 문제해결하는 방식으로 리팩토링했습니다.)

*피드백을 반영하는 과정에서 도메인 재구성이 필요하다고 생각했습니다. 그래서 리팩토링 과정에서 많은 파일이 바뀌었습니다.🥲
*깃을 제대로 못 만져서, 사이클 1의 커밋 내용도 전부 뜨는 것 같습니다. (보기 힘드실거 같아서 죄송합니다..)
*사이클 1에서 달아주신 리뷰 답글은 14일(토)내로 작성해두겠습니다!

사이클 1의 PR

링크: #956

미션 중 기록

1. 기능 추가로 인해 수정한 위치 개수

기능을 추가하는 과정에서 현재 구조로 확장하기에 어려움이 있었다.
그래서 대부분의 비즈니스 로직을 도메인 안으로 넣어서, 변경에 유연하도록 도메인을 재구성하였다.

1)BlackjackResult삭제
원래는 BlackjackResult에서 승패와 같은 게임의 기록을 저장했는데,
배팅 상금이라는 결과가 하나 더 추가 되면서, 출력 결과(response)를 도메인으로 갖는 것은 확장성이 안좋다고 생각했다.
그래서 BlackjackResult를 없애고, Game이라는 도메인에서 그때그떄 원하는 결과를 반환할 수 있도록 메서드만 구현하였다.

2)Deck 도메인 추가, Cards 일급 컬렉션 수정
Cards라는 일급 컬렉션을 카드 전체(52장)를 타깃으로 사용했다 보니, Player가 갖는 카드 더미는 Cards를 사용하지 못했다.
전체 카드는 랜덤 생성, 카드 추출 기능에 대한 책임만 가지기 때문에 플레이어가 가지는 카드 뭉치 Cards와 따로 분리하는 것이 낫다고 생각했다.
그래서 Player가 소유한 카드 뭉치를 Cards라는 일급 컬렉션으로 사용하기 위해, 전체 카드를 나타내는 Deck이라는 도메인을 추가하였다.
CardGenerator를 파라미터로 받아서 전체 카드 생성에 관해서 Deck에서 처리하도록 하였다.
카드 생성을 저번에 인터페이스로 해서 분리하니 이부분에 대한 수정은 편리했다.
(CardGenerator를 파라미터로 받아서 메서드로만 호출하면 되니까.)

4)Game 도메인 추가, Dealer 도메인 삭제
Game에 대한 비즈니스 로직이나 규칙들이 Player, Dealer, Cards 등에 흩어져있어 테스트 코드 작성에 어려움이 있었다.
따라서, 블랙잭 게임 규칙에 대한 메서드를 모아두기 위해 Game이라는 도메인을 추가하였다.

Game을 추가하고 나니 Dealer의 필드는 Player와 겹치고, Dealer의 규칙은 Game에서 수행할 수 있을 것으로 보았다.
(16이하이면 카드를 더 받는다는 Dealer의 규칙은 게임의 규칙이라고 볼 수도 있기 때문이다.)
Game과 Dealer는 항상 1대 1로 존재하기 떄문에, 객체 생성-소멸 주기가 같다고 판단하여 관련 로직을 Game에 두었다.

추가로 Dealer는 게임을 만들 때 외부에서 주입해주는 방식으로 했다. 그래야 GameTest에서 Dealer의 카드를 조작해줄 수 있기 때문이다.
테스트를 작성하며 의존성을 줄이는 방향으로 개발을 하게 되었다.

2. 사이클1 때보다 수정 범위가 줄었는가/늘었는가

사이클 1에서 단편적인 결과 출력에만 집중해서 도메인을 설계해서 그런지, 기능 추가를 위해 코드 변경이 막막하고 어려웠다.
그래서 도메인을 재구성하였기 때문에, 사이클1 때보다 수정 범위가 훨씬 컸다.
변경된 구조에서는 기능 추가 시 Game에 코드를 추가하면 되기 때문에, 코드 변경이 적을 것으로 예상된다.

3. 규칙 적용으로 변경한 코드 1곳

(If-Then) 하드코딩된 값이 보인다면, → 상수화한다.
도메인으로 로직을 이동하면서, 상수도 적절한 도메인으로 이동해 응집성 있게 수정하였다.

(If-Then) 같은 객체를 다루는 클래스여도 목적이 다르면, → 클래스를 분리한다. (e.g. Cards -> Deck, Hand)
Cards를 Cards(Player 소유 카드), Deck(전체카드)으로 나누어서 리팩토링하였다.

4. 테스트가 설계를 도운 순간 1회

게임 규칙에 대한 테스트를 진행하려고 했는데,
이런 규칙이 Player, Dealer, Cards 등 여러 도메인에 걸쳐서 존재하는 것이 불편했다.
테스트 구현을 통해 도메인의 책임 분리에 대한 재구성 필요 신호를 포착할 수 있어서 설계에 도움이 되었다.

체크 리스트

• 미션의 필수 요구사항을 모두 구현했나요?
• Gradle test를 실행했을 때, 모든 테스트가 정상적으로 통과했나요?
• 애플리케이션이 정상적으로 실행되나요?